Fix NativeWatcher missing changes made straight after startup - #2003

`NativeWatcher.startWatching` resolves as soon as `fs.watch` returns, but on macOS that can be before any events are delivered. libuv only signals another thread to (re)create the FSEvents stream, and the stream reports only changes made after it starts:

https://github.com/libuv/libuv/blob/2b4b918d3381100854250c89d5159d4206daafb7/src/unix/fsevents.c#L362-L372

So a change made immediately after startup can be silently missed. On a slow host the gap is long enough to hit regularly - it's the remaining flake in the Native watcher integration tests, where the suite's first event never arrives. 14 of 297 macOS test jobs since #1974 hit it, across all three Node versions.

This adds a `probe` option for watcher backends. `Watcher` passes one that writes a health check file to the backend's root and waits for it to be reported, and `NativeWatcher` probes until one is observed before resolving. If it can't confirm within 10s, Metro warns and carries on.

Note that `NativeWatcher`s for multiple roots share one FSEvents stream, which restarts as each root is added, so the guarantee is for `Watcher.watch()` as a whole rather than each backend.

Changelog:
```
 - **[Fix]**: Fix changes made immediately after startup sometimes being missed on macOS
```

Test plan:
New unit tests for the probe loop. The integration tests now pass their own probe.

To reproduce the race locally, I patched `NativeWatcher` to drop all events for its first 300ms:
 - The Native integration tests fail as on CI without a probe ("detects a new, changed, deleted file" times out in its hook), and pass with this PR.
 - A `FileMap` in watch mode with two roots, writing a file to each as soon as `build()` resolves, sees neither change without a probe (3/3 runs) and both with this PR (3/3).
 - Dropping events indefinitely, `build()` resolves after 10s with a warning per root, and no health check files are left behind.